Many backbones of modern communication such as GSM (Global System for mobile communications) and UMTS (Universal Mobile Telecommunications System) wireless systems and undoubtedly the Internet as the most adopted wired data network transfer multiple types of data over a number of different interfaces by utilizing a plurality of protocols. Concerning both payload data and signalling transfer, the development of protocols has been separated in many diverging directions naturally depending on the various requirements originally set for the specific protocol under development. A protocol as an entity can be concretised as a composition of rules describing how to transfer data across the network and the functionality to implement the data transfer in practise.
As modern applications and the increased amount of data traffic in general put more and more pressure on the used protocols, especially the efficiency of a protocol implementation used in the transport system should be optimized. The protocol implementation is often considered as a maximally efficient one when it provides all the needed communication services in such a way that the use of the protocol requires only minimal amount of hardware and network resources in the end system. The needed communication services typically cover the essential functionalities according to a requested Quality of Service (QoS) level. QoS represents the desired performance properties of a network service generally including throughput, delay, and priority levels for data transfer.
The communication services provided by the protocols in existing general-purpose protocol stacks such as the well-known Open System Interconnection (OSI) reference stack by ISO (International Standardization Organization) with seven layers (physical, data link, network, transport, session, presentation, application) or the closely related TCP/IP (Transmission Control Protocol /Internet Protocol) reference stack are not always adequate for all specific purposes the one may come up with. See reference [1] for further information about the above protocols. In order for a protocol to provide the necessary services and at the same time, place only minimal requirements for available hardware and network resources, the protocol has to be designed according to some specific requirements.
The user of a protocol may be e.g. a lower or higher level protocol or an application. Services provided by the protocol may be accessed via service primitives that define the format and content of the exchanged information. Primitives that are exchanged through Service Access Points (SAP) between successive protocol layers (or between equivalent protocol layers located in different systems) may include user originated data, control and management parameters. The primitives can be divided into four basic classes: requests, indications, responses, and confirmations. Typically a higher layer protocol entity requests some service from a lower layer protocol, receives indication about events from lower layer protocols, and responds to events taken by the lower layer protocol, whereas the lower layer protocol may confirm the events requested by the upper layer protocol.
Protocol functionalities required by the services are realized with data processing, control and management functions respectively. Control functions, e.g. flow, queue, and timing functions, are used to control the data flow through the protocol, for example. Data processing functions, e.g. encryption, error detection, error correction, and fragmentation, manipulate the data itself instead. Management functions like management information base (MIB) functions are associated with monitoring, network level control, power management, protocol state etc.
The control and data functions can be considered as a sequential set of operations, which are executed upon data flow through the protocol. In addition to processing data, each operation can among others branch, buffer, and synchronize data flow. On the contrary, the management functions can be viewed as a set of operations performed substantially in parallel with both control and data functions.
As described hereinbefore, a protocol implementation has a certain structure defining relations between the protocol functions. The structure fixes the consistence of the data flow and defines the composition of control, data, and management functions.
A common problem with contemporary protocol arrangements, however, arises from the evident staticity of the protocol structures tailored for some specific use. Such protocols may be effective from the user's perspective if any modifications or additions are not needed thereto but in case of change in the desired requirements the protocol may have to be at least partly if not completely re-implemented with a renewed hardware and/or software structure.
Publication [2] discloses a design concept of a generic protocol stack for an adaptive terminal. As in mobile networks the features of both UMTS/GSM mobile system and the DECT (Digital Enhanced Cordless Telecommunications) cordless phone system might seem advantageous, the adaptive terminal should incorporate a protocol stack supporting all these systems with some shared resources. Therefore, a protocol stack-skeleton is built upon which the system specific parts are then adapted to. The publication concentrates on finding similarities between GSM, UMTS, and DECT systems from which DECT and UMTS seem to match each other reasonably well in contrast to the older GSM system that has a slightly differing structure what comes to the overall layer division.
Publication [3] discloses a protocol and a protocol framework comprising a generic model of protocol processing, a metaheader protocol supporting per-packet configuration of protocol function, and a set of protocol functions. Protocol functions are not layered and thus they do not attach headers (or extract them) to data units; header attach/detach is performed by the generic model that defines the interface between the actual protocol infrastructure and functions thereof. Metaheader protocol implements multiplexing and composition mechanisms and contains information both for retrieving state information of the incoming data unit efficiently and for indicating which set of protocol functions should be applied to the incoming data unit and possibly in what order they should be utilized. Protocol configurations can be dynamically altered via metaheaders that all data units carry. Configurability is carried out on a plurality of levels: global configuration, connection based configuration (defined at connection start-up by both ends of the communication), and message specific configuration. Moreover, protocol functions are divided into three classes: generic, functions affecting the metaheaders, and functions affecting the internal protocol structure but not appearing in the metaheaders (like data flow control).
Notwithstanding the aforementioned improvements in protocol planning a number of defects are still left more or less intact. In general sense, the prior art methods can be classified as follows: in the first method being the most obvious one a preferred protocol stack may be selected from several permanently fixed complete stacks. This approach causes a multiplicity of overhead originated from the duplication of similar functions included in different stacks and the inclusion of unnecessary functionalities in the end result. The second method solves the problem by offering various partial protocols used to compose application specific complete stacks. In this method the configuration does not modify the functionality of a single partial protocol that is already fixed and used as is [2]. This method includes less overhead than the first method, but there is still functional duplication or unnecessary functionality that cannot be avoided. The most flexible method provides atomic protocol functions composing the dynamic structure [3]. The problems not addressed by this method are related, for example, to the scheduling of protocol processing and management of the protocol in efficient manner.